Add cheri_revoke_shm_anon_hoard_unmapped which:
 - creates and maps a shared memory object
 - stores a pointer to malloced memory in the mapped object
 - unmaps the object
 - frees the pointer and triggers revocation
 - remaps the object
 - checks that the stored pointer was revoked (it is not)

Add cheri_revoke_shm_anon_hoard_closed which:
 - creates and maps a shared memory object
 - stores a pointer to malloced memory in the mapped object
 - unmaps the object
 - send the shared object file descriptor to a child process
 - closes the file descriptor
 - frees the pointer and triggers revocation
 - receives the file descriptor back from the child process
 - remaps the object
 - checks that the stored pointer was revoked (it is not)

This demostrates the futility of scanning the descriptor table for
shared memory objects during revocation and the necessity to bind them
to an address space.  (Lest one think it's possible to walk the graph
of sockets to find the graph of processes that might have a shared
memory object to search, the child could be replaced by a completely
independent hoarder daemon running on a unix domain socket in the file
system.)